In recent years, mobile stations have become “must have” devices for most people, in many countries. The communications that such devices offer, via wireless mobile communications network, enable users to talk and exchange various types of messages for business and personal reasons and to access information, all from or while traveling through any location where a network provides compatible wireless communication service.
In support of these activities, mobile stations run many applications for their users, which need to display and process device-specific or account-specific information stored in servers which are customer-proprietary and privacy-sensitive. If a device application needs to retrieve customer data from a server through the carrier network and process or display the data on the mobile station, device authentication and user identification must be done first.
The system must ensure that the device belongs to a valid account and the account was authorized to use data connectivity of the wireless carrier. This involves both device authentication and account identification. Hence, when a server receives a request from such an application, the first thing it needs to do is to authenticate the device, that is to say, determine that the device belongs to a valid and active account. Once this device authentication is done, correct identification of the account is the next step. Typically, the system must determine the correct mobile telephone number (or account) of the mobile device. Only then it will be able to pull device-specific information from the databases of carrier network and send it to handset for further processing.
A common practice is to challenge users for a user login identifier (ID) and a password. However, this approach is not optimal in the context of mobile station applications. The flowchart of FIG. 6 represents an outline of the events that usually take place during the start of a typical mobile application that mimics traditional web paradigm, with User ID/Password challenge.
At step p1, the customer starts the mobile device-resident mobile station application that will access a network database to retrieve and/or process customer-specific data. In order to do user identification and authentication, a login page is displayed prompting the user for User ID and Password. In step p2, as the user submits the login page containing ID and Password, and the application causes the mobile station to send the ID and Password information to the application server.
Next (step p3), the application server sends the login information to an authentication server. The authentication server could be a separate physical server or another module of the server application. In step p4, the authentication server queries a network database for user-entered ID-Password combination. At step p5, the authentication server matches the query result, to determine if the user-entered ID-Password combination matches those of a valid mobile station account. If a match is found, at step p6, then the authentication server sends the identity information of the user to the application server.
At step p7, the application server uses the identity information to retrieve appropriate customer data from the system and sends the retrieved customer data to the application running in the mobile station. The application server also establishes a session through the network with the application running on the mobile station. As long as the session continues, the identity information is used whenever needed.
However, if a match was not found, at step p8, the user is redirected to the login page. The cycle may repeat/continue until a valid ID-password combination is submitted.
This method may work fine in the traditional web paradigm where the user accesses an application using a personal computer (PC), but it poses a huge security risk and significant user inconvenience when applied to mobile devices.
For most of the relevant mobile applications, security is a critical concern to the service provider. When a mobile user launches an application that interacts with servers, the carrier must ensure that the requesting device is an authorized one, because the carrier cannot allow unauthorized devices to access its network or its sensitive/valuable information. Also, the carrier needs to ensure the device was provisioned for data usage, e.g. to avoid fraudulent access to paid subscription services. In other words, the account (the device belongs to) must have a valid data plan and be allowed to use the data network. To use the data network, specific features must be provisioned for a carrier-authorized device. Before allowing data traffic from that particular device to go through carrier's network, the system needs to make sure the device had proper allowance. However, unauthorized users can sometimes spoof the User ID and Password entries, compromising the service with regard to these security concerns.
User experience also presents concerns. Many mobile devices today do not have a full keyboard or data entry pad. Typing accurately on a mobile device having a limited keypad is not an easy task, for many average users. Entering data against the User ID/Password challenge may be difficult and frustrating. The requirement for user inputs for authentication therefore significantly impacts the user experience. Mobile users always prefer systems that require minimum user inputs or keystrokes.
For at least the reasons outlined above, mobile applications need a transparent device authentication and user account identification mechanism that requires little or no user input.